PDF Content

PARADIGMA ORIENTADO A OBJETOS

Conceitos Básicos

INCIDÊNCIA EM PROVA: média

Um dos maiores problemas da programação estruturada é que, muitas vezes, partes do código que servem apenas para tratar os dados se misturam com partes do código que tratam da lógica do algoritmo. Essa prática não é saudável, na medida em que diminui a reusabilidade e dificulta leitura, depuração e manutenção. A modularização da programação estruturada foi um grande avanço na busca pela reusabilidade de código, mas nem se compara ao que trouxe a programação orientada a objetos. Esse novo paradigma reflete bem mais fielmente os problemas atuais. É um paradigma que se baseia na abstração de coisas ou objetos do mundo real em um sistema de forma potencialmente reusável! A reusabilidade de classes melhora a agilidade e permite que programas sejam escritos mais rapidamente... Galera, vocês trabalham com isso e sabem que a demanda só aumenta, logo existe uma busca por maneiras de se desenvolver sistemas de forma mais rápida! Para quê reinventar a roda? Nada disso! Devemos aproveitar tudo que puder ser aproveitado. Além disso, é importante citar a escalabilidade. Softwares construídos seguindo os preceitos da orientação a objetos são mais escaláveis, isto é, podem crescer facilmente sem aumentar demasiadamente sua complexidade ou comprometer seu desempenho. É possível construir tanto um software da Padaria do João quanto o sistema que controla o Acelerador de Partículas da NASA. Outra grande vantagem do paradigma é o seu caráter unificador, isto é, tratar todas as etapas do desenvolvimento de sistemas e ambientes sob uma única abordagem. Nesse sentido, podemos ter análise, projeto, modelagem, implementação, banco de dados, e ambientes orientados a objetos. Isso elimina as diferenças de paradigmas utilizadas em cada um desses contextos. O Paradigma Orientado a Objetos (POO) visualiza um sistema de software como uma coleção de agentes interconectados chamados objetos. Cada objeto é responsável por realizar tarefas específicas e é por meio da interação entre objetos que uma tarefa computacional é realizada. Galera, vocês conseguem perceber que a sociedade utiliza o conceito de objetos cotidianamente para resolver seus problemas?

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Pois é, já é algo natural! Ele auxilia a modelagem de sistemas, reduzindo a diferença semântica entre a realidade sendo modelada e os modelos construídos. Um sistema orientado a objetos consiste em objetos em colaboração com o objetivo de realizar as funcionalidades desse sistema. Cada objeto é responsável por tarefas específicas e a cooperação entre eles é importante para o desenvolvimento do sistema. O POO tem a finalidade maior é a de facilitar a vida dos programadores para que eles consigam desenvolver softwares que satisfaçam os clientes, transformando coisas do dia a dia em objetos e permitindo que sejam empregados os seus recursos de forma eficaz. O POO tem evoluído em questões voltadas para segurança e reaproveitamento de código – requisitos estes considerados importantes no desenvolvimento de qualquer aplicação moderna. Vejamos as principais vantagens:

VANTAGENS DO PARADIGMA ORIENTADO A OBJETOS

Produção de software natural. Os programas naturais são mais inteligíveis. Em vez de programar em termos de regiões de memória, o profissional pode programar usando a terminologia de seu problema em particular. Programas orientados a objetos, bem projetados e cuidadosamente escritos são confiáveis. Pode-se reutilizar prontamente classes orientadas a objetos bem-feitas. Assim como os módulos, os objetos podem ser reutilizados em muitos programas diferentes. Um código orientado a objetos bem projetado é manutenível. Para corrigir um erro, o programador simplesmente corrige o problema em um lugar. Como uma mudança na implementação é transparente, todos os outros objetos se beneficiarão automaticamente do aprimoramento. O software não é estático. Ele deve crescer e mudar com o passar do tempo, para permanecer útil. A programação orientada a objetos apresenta ao programador vários recursos para estender código. Esses recursos incluem herança, polimorfismo, sobreposição e uma variedade de padrões de projeto. O ciclo de vida do projeto de software moderno é frequentemente medido em semanas. A programação orientada a objetos ajuda nesses rápidos ciclos de desenvolvimento. Ela diminui o tempo do ciclo de desenvolvimento, fornecendo software confiável, reutilizável e facilmente extensível.

O Paradigma Orientado a Objetos (POO) possui alguns princípios básicos ou pilares fundamentais, como é possível ver na imagem ao lado. Os princípios são: Encapsulamento, Herança e Polimorfismo. E a abstração, professor? Galera, alguns autores afirmam que esses princípios são todos simplesmente a aplicação de um único conceito: o princípio da abstração. Vejam pela imagem que a abstração é a base que sustenta todos os outros pilares desse paradigma. Nós veremos cada um desses princípios em detalhes nos próximos tópicos porque eles despencam em prova. Fechado?

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Classes e Objetos

INCIDÊNCIA EM PROVA: Altíssima

Objetos são coisas (Carro, Foto, Bola, etc) e classes são um agrupamento de coisas. A classe é a descrição dos atributos e serviços comuns a um grupo de objetos (reais ou abstratos), logo podemos dizer que é um modelo a partir do qual objetos são construídos. Além disso, objetos são instâncias de classes. O que é um carro? Posso abstrair um carro como um objeto que tem motor, volante, porta, rodas, entre outros. Ora, existem carros que têm dois motores (um elétrico e um à gasolina), outros têm somente duas portas. Como nós sabemos que ambos são carros? Porque, independentemente de pequenas diferenças entre as instâncias, nós conseguimos entender que se trata de carros. Para fins de modelagem de um sistema, somente um subconjunto de características é relevante, logo ignoramos o restante.

São componentes de um objeto: identidade, estado (propriedades) e comportamento (operações). A identidade é responsável por distinguir um objeto dos outros, isto é, eles são únicos, mesmo que sejam instâncias de uma mesma classe e que tenham os mesmos valores de variáveis.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

O estado reflete os valores correntes dos atributos do objeto em um determinado momento. Entenderam esse conceito? Já o comportamento se refere a como os objetos reagem em relação à mudança de estado e troca de mensagens, isto é, trata-se de um conjunto de atividades externamente observáveis do objeto. Dito isso, vamos resumir o que vimos até agora nesse tópico? Identidade é o que torna o objeto único; Estado se refere aos seus atributos; e Comportamento se refere aos seus métodos e procedimentos. Bacana? Um objeto é capaz de armazenar estados por meio de seus atributos e reagir a mensagens enviadas a ele, assim como se relacionar com outros objetos e enviar mensagens. Já a classe é como um projeto, formato ou descrição geral de um objeto! São abstrações do domínio do problema, não são diretamente suportadas em todas as linguagens, mas são necessárias em linguagens orientada a objeto.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

==76484==

Atributos

INCIDÊNCIA EM PROVA: Altíssima

Consiste em uma informação de estado para o qual cada objeto de uma classe tem seu próprio valor. Há dois tipos: atributos de objetos e de classes. O primeiro descreve valores mantidos em um objeto. Diferentes objetos de uma mesma classe não compartilham os atributos de objetos, isto é, cada um possui sua própria cópia do atributo. O segundo é aquele cujo valor todos os seus objetos devem compartilhar. As mensagens enviadas a um objeto (isto é, a chamada de um método) podem mudar o valor de um ou mais atributos, alterando o estado de um objeto. Um atributo é um dado para o qual cada objeto tem seu próprio valor. Atributos são, basicamente, a estrutura de dados que vai representar a classe. Galera, não tem muito o que falar sobre esse tema não, é isso mesmo! Vamos ver os escopos de atributos:

TIPO DE ATRIBUTO DESCRIÇÃO

ATRIBUTO DE CLASSE

Similar a uma variável global, trata-se de uma variável cujo valor é comum a todos os objetos membros de uma classe. Mudar o valor de uma variável de classe em um objeto membro automaticamente muda o valor para todos os objetos membros.

ATRIBUTO DE INSTÂNCIA

Trata-se de uma variável cujo valor é específico ao objeto e, não, à classe. Em geral, possui um valor diferente para cada instância. As linguagens de programação possuem palavras para definir o escopo da variável (Ex: em Java, por padrão, é de instância; para ser de classe, deve vir precedida de static).

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Métodos

INCIDÊNCIA EM PROVA: Altíssima

Similares a procedimentos e funções, os métodos consistem em descrições das operações que um objeto executa quando recebe uma mensagem. Existe, portanto, uma correspondência um- para-um entre mensagens e métodos que são executados quando a mensagem é recebida através de um objeto. A mesma mensagem pode resultar em métodos diferentes quanto enviada para objetos diferentes. Existe um método que nós devemos conhecer bem: método construtor! Os métodos construtores são métodos especiais, que são chamados automaticamente quando instâncias são criadas. Seu objetivo é garantir que o objeto será instanciado de forma correta. Ele tem exatamente o mesmo nome da classe em que está inserido, não possui tipo de retorno e não é obrigatório declará-lo. Bacana? Por meio da criação de construtores, podemos garantir que o código que eles contêm será executado antes de qualquer outro código de outros métodos. Eles geralmente são usados para preparar um objeto, inicializando as variáveis do objeto. Pode existir mais de um método construtor em uma classe através da sobrecarga de construtores. Em algumas linguagens, são acionados por meio do operador New.

TIPO DE método DESCRIÇÃO

Método DE CLASSE

Similar a um método global, trata-se de um método que realiza operações genéricas, isto é, não relativas a uma instância particular. Linguagens de programação possuem palavras para definir o escopo do método (Ex: em Java, deve vir precedida de static).

Método DE INSTÂNCIA

Similar a um método local, trata-se de um método que realiza operações específicas para um objeto e, não, à classe, isto é, são relativas a uma instância particular. Por padrão, todos os métodos de uma determinada classe são considerados métodos de instância.

Cabe salientar que um método nada mais é que uma definição, pois a ação em si somente ocorre quando o objeto é invocado através de um método – por meio de uma mensagem! Para quem lembra de programação estruturada, métodos são similares a procedimentos ou funções. Eles definem o comportamento a ser exibido pelas instâncias da classe associada em tempo de execução. Em tempo de execução, eles possuem acesso aos dados armazenados em um objeto que estão associados e são, desta forma, capazes de controlar o estado da instância. A associação entre classe e método é chamada de ligação (Binding). Um método associado a uma classe é dito ligado (Bound) à classe. Existem dois tipos de ligações: Early Binding (Ligação Prematura) e Late Binding (Ligação Tardia). Vejamos...

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

TIPO DE ligação DESCRIÇÃO

Early binding ^{Também conhecida como Ligação Estática, ocorre quando o método a ser}

invocado é definido em tempo de compilação.

Late binding ^{Também conhecida como Ligação Dinâmica, ocorre quando o método a ser}

invocado é definido em tempo de execução.

Aqueles que já conhecem um pouco sobre orientação a objetos, respondam-me: Qual desses tipos de ligação é o mais comum quando utilizamos polimorfismo? Late Binding!

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Mensagens

INCIDÊNCIA EM PROVA: Altíssima

Galera, qual é a utilidade de um objeto isolado? Nesse contexto, ele é geralmente muito pouco útil! Por meio da interação entre objetos é que se torna possível obter uma grande funcionalidade ou um comportamento mais complexo. Logo, assim como no mundo real, objetos estão sempre interagindo uns com os outros. Bem... essa interação ocorre por meio de troca de mensagens. Como assim, professor? É bom sempre pensar em nosso dia a dia! Imaginemos uma pessoa dirigindo um carro e pensemos em como modelar essa ação para o mundo orientado a objetos! Podemos imaginar um Objeto Pessoa enviando uma mensagem para o Objeto Carro, dizendo-lhe para acelerar, frear, trocar marcha, virar, ligar, desligar, etc. Um objeto manda outro objeto realizar alguma operação enviando-o uma mensagem.

Pois bem, algumas vezes o objeto receptor necessita de algumas informações para realizar o que lhe foi requisitado! Por exemplo: Objeto Carro precisa saber quanto é para acelerar, que horas frear, para qual marcha trocar, etc e o Objeto Pessoa precisa informá-lo. Como ele pode fazer isso? Ele envia a mensagem acompanhada de um conjunto de parâmetros ou argumentos que podem afetar as operações. Uma mensagem é composta por três componentes: objeto, a quem a mensagem é endereçada; nome do método ou serviço que se deseja executar; e parâmetros necessários ao método (se existirem). Logo, podemos dizer que mensagens são requisições enviadas de um objeto para outro com o intuito de receber algo em retorno por meio da execução de uma operação. A natureza das operações realizadas para alcançar o resultado requerido é determinada pelo objeto receptor. Em suma, trata-se de um ciclo completo onde uma mensagem é enviada a um objeto, operações são executadas dentro desse objeto e uma mensagem contendo o resultado da operação é enviada

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

ao objeto solicitante. Em nosso paradigma, objetos vivem dando ordens para outros objetos executarem métodos (ou realizarem serviços). O bacana disso tudo é que objetos em processos distintos, máquinas distintas ou redes distintas podem comunicar-se através de mensagens. E daí, professor? E daí que isso aumenta a coesão e diminui o acoplamento, melhorando substancialmente a reusabilidade! Algumas vezes, sistemas de software possuem tratadores (handlers) de mensagens! Eles são responsáveis por processar mensagens de mais de um transmissor. Em outras palavras, eles recebem mensagens de diversos objetos e encaminham para seus respectivos donos. Relaxem, nós veremos isso mais à frente com o conceito de polimorfismo!

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Abstração

INCIDÊNCIA EM PROVA: Altíssima

De modo simples e direto: abstração é a subtração de detalhes, isto é, quanto mais abstrato, há menos detalhes; e quanto menos abstrato, há mais detalhes. Observem as imagens abaixo: trata- se de uma visão aérea da Catedral de Brasília! Na primeira imagem, há muitos detalhes; a segunda imagem é uma abstração em que se subtraiu diversos detalhes que não são relevantes para o domínio do problema. Vejamos...

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

A abstração é um processo mental pelo qual nós seres humanos nos atemos aos aspectos mais importantes/relevantes de algo, ao mesmo tempo que ignoramos aspectos menos importantes. Esse processo mental nos permite gerenciar a complexidade de um objeto ao mesmo tempo que concentramos nossa atenção em suas características essenciais. Note que a abstração depende da perspectiva (contexto) sobre a qual ela é analisada. Temos que falar também sobre classes abstratas e concretas. Uma classe abstrata é desenvolvida para representar entidades e conceitos abstratos. Ela é sempre uma superclasse que não possui instâncias. Ela define um modelo/template para uma funcionalidade e fornece uma implementação incompleta (isto é, a parte genérica dessa funcionalidade) que é compartilhada por um grupo de classes derivadas. Cada uma das classes derivadas completa a funcionalidade da classe abstrata adicionando comportamentos específicos. Por outro lado, classes concretas implementam todos os seus métodos e permitem a criação de instâncias. Em suma: classes concretas são aquelas que podem ser instanciadas diretamente e classes abstratas, não. Há também métodos abstratos: aqueles para os quais não é definida uma forma de implementação específica¹.

1 É possível haver uma classe abstrata contendo somente métodos concretos. No entanto, se ela tiver um único método abstrato, que seja, deverá ser declarada como abstrata!

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Interface

INCIDÊNCIA EM PROVA: Altíssima

Sabemos que classes abstratas são aquelas que são desenvolvidas para representar entidades e conceitos abstratos. Elas geralmente contêm ao menos um método abstrato (sem corpo) e não se pode criar uma instância dela. As classes abstratas são usadas para serem herdadas e funcionam como uma superclasse. Nós podemos dizer, então, que se trata de um contrato para que alguma subclasse concretize seus métodos. No entanto, agora vamos falar de um novo conceito: interfaces. Esse é um tópico que gera muita confusão porque se trata realmente de um conceito parecido com as classes abstratas. Para entender a diferença entre uma interface e uma classe abstrata, devemos nos ater a uma parte importante da definição apresentada no parágrafo anterior: “(...) ela deve conter pelo menos um método abstrato (sem corpo)”. Em uma classe qualquer, existem três possibilidades: 1. Se a classe possui pelo menos um método abstrato, será obrigatoriamente abstrata; 2. Se a classe possui todos os métodos abstratos, será obrigatoriamente abstrata; 3. Se a classe possui todos os métodos concretos, poderá ser concreta ou abstrata. No primeiro caso, é fácil verificar que a classe é abstrata se ela tem pelo menos um método abstrato; no segundo caso, também é fácil notar que – se todos os métodos são abstratos – ela também deverá ser abstrata; já no terceiro caso, mesmo quando todos os métodos são concretos, ainda assim eu posso declará-la como abstrata – isso é uma decisão do designer da classe. Ele será responsável por defini-la da maneira que achar mais adequada. Agora voltemos um pouco para o segundo caso! Se todos os métodos são abstratos, a classe será abstrata! Professor, uma interface é uma classe? Não, uma interface é uma entidade em que todos os métodos são obrigatoriamente abstratos. Opa, perceberam a semelhança? Existem classes abstratas que contêm todos os métodos abstratos exatamente como uma interface (Caso 2). Vejamos, portanto, quais são as diferenças...

características Interfaces Classe abstrata

Herança Múltipla ^Suporta

Herança Múltipla. Pode implementar diversas interfaces.

Não suporta Herança Múltipla. Não pode estender várias classes abstratas.

Implementação ^{Não pode conter qualquer método concreto,}

apenas abstratos.

Pode conter métodos concretos ou abstratos.

Constantes ^{Suporta somente constantes estáticas.}

Suporta constantes estáticas e de instância.

Encapsulamento ^{Métodos e membros devem sempre ser}

públicos por padrão.

Métodos e membros podem ter qualquer visibilidade.

Membros de Dados ^{Não contêm atributos de instância, apenas}

constantes.

Pode conter atributos de instância. Construtores Não contém construtores. Contém construtores.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Velocidade ^{Em geral, são mais lentas que classes}

abstratas.

Em geral, são mais rápidas que interfaces.

Dessa forma, pode-se dizer que uma interface é similar a uma classe abstrata. Aliás, podemos dizer que uma interface é praticamente uma classe abstrata pura, isto é, todos os seus métodos são abstratos. Uma classe concreta – ao implementar uma interface – deverá escrever o corpo de todos os métodos. Observem, portanto, que uma classe abstrata pode também implementar uma interface sem nenhum problema. Uma aluna certa vez me perguntou a diferença entre classe abstrata e interface e também quando se deve utilizar uma ou quando se deve utilizar a outra. Galera, lembre-se que a classe abstrata pode conter métodos concretos, então se você quer representar métodos concretos, você pode utilizar classes abstratas, mas não poderá jamais utilizar interfaces (que não pode conter métodos concretos). Existe outra diferença importante: você pode declarar variáveis em classes abstratas, mas se você declarar uma variável em uma interface, ela não terá o comportamento de uma variável, mas – sim – de uma constante (será implicitamente public static final). Não é papel da interface lidar com o estado interno de um objeto – é muito raro ver atributos em uma interface. Por fim, se você usar uma classe abstrata pura, realmente não tem muitas diferenças práticas em relação a interfaces. De todo modo, conceitualmente, uma classe abstrata especifica o que um objeto é; uma interface especifica o que um objeto pode fazer.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Encapsulamento

INCIDÊNCIA EM PROVA: Altíssima

Galera, nós já vimos que objetos possuem comportamentos. Correto? Já vimos que eles realizam operações em outros objetos, conforme recebam mensagens. O mecanismo de encapsulamento é uma forma de restringir o acesso ao comportamento interno de um objeto. Um objeto que precise da colaboração de outro objeto para realizar alguma operação simplesmente envia uma mensagem a este último. Segundo o mecanismo do encapsulamento, o método que o objeto requisitado utiliza para realizar a operação não é conhecido dos objetos requisitantes. Em outras palavras, o objeto remetente da mensagem não precisa conhecer a forma pela qual a operação requisitada é realizada; tudo o que importa a esse objeto remetente é obter a operação realizada, não importando como. No entanto, o remetente da mensagem precisa conhecer pelo menos quais operações o receptor sabe realizar ou o que ele pode oferecer. Para tal, as classes descrevem seus comportamentos por meio de uma interface! Ela descreve o que o objeto sabe fazer, sem precisar detalhar como ele fará! Vamos ver um exemplo? Quando enviamos uma encomenda para alguém em outro país, eu pago pelo serviço de entrega internacional oferecido pelos Correios e só... Eu não quero saber se ele vai de avião, trem, navio, submarino! Como ele fará para entregar minha encomenda não me importa, o que importa é que ele entregue a encomenda. Logo, a interface de um objeto deve definir os serviços que ele pode fornecer. Através do encapsulamento, a única coisa que um objeto precisa saber para pedir a colaboração de outro objeto é conhecer a sua interface. Nada mais além disso... Isso contribui para a autonomia dos objetos, pois cada objeto envia mensagens a outros objetos para realizar certas operações, sem se preocupar em como se realizaram as operações. Qual a vantagem disso? A interface permite que a implementação de uma operação pode ser trocada sem que o objeto requisitante dela precise ser alterado. Isso mantém as partes de um sistema tão independentes quanto possível. Daí a importância do mecanismo do encapsulamento no desenvolvimento de software orientado a objetos. Pessoal, existe o conceito de especificadores ou modificadores de acesso. Conhecidos também como visão de método ou visão de atributo, definem a visibilidade de um atributo, método ou classe. Em geral, utilizam-se especificadores de acesso para privar o acesso direto a atributos e obrigar o usuário a fazê-lo por meio de métodos públicos.

MODIFICADOR/ESPECIFICADOR CLASSE PACOTE SUBCLASSE TODOS

uml PÚBLICO + x x x x

PROTEGIDO # x x

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Polimorfismo

INCIDÊNCIA EM PROVA: Altíssima

O polimorfismo trata da capacidade de abstrair várias implementações diferentes em uma única interface. Imaginem que vocês tenham um videocassete antigo e, em determinado dia, ele decida parar de funcionar! Você o joga no lixo, mas mantém seu controle remoto. Meses depois, compra um blu-ray da mesma marca e, de repente, seu controle remoto antigo funciona também no aparelho novo! Olha que maneiro! Dois objetos, um novo e um antigo, respondem à mesma mensagem! E no mundo da orientação a objetos? Nesse contexto, o polimorfismo diz respeito à capacidade de duas ou mais classes de objetos responderem à mesma mensagem, cada qual de seu próprio modo. Pensem em uma coleção de formas geométricas que contenha círculos, retângulos e outras formas específicas. Seguindo os princípios de polimorfismo na orientação a objetos, nós podemos facilmente calcular a área de todas essas figuras geométricas! No entanto, vocês sabem que o cálculo da área de círculo é diferente do cálculo da área de um retângulo, que é diferente do cálculo da área de um trapézio, que é diferente da área de um triângulo, etc. Pois é... vamos relembrar um pouquinho das aulas de trigonometria da escola? Para calcular a área do círculo, é necessário saber o raio; do retângulo, é necessário saber a base e a altura; do trapézio, é necessário saber a base maior, base menor e altura; e do triângulo, é necessário saber a base e altura. Ora, para aplicar o polimorfismo, eu devo enviar a mesma mensagem e ele se virar para entender qual área ele deve calcular! E como ele faz isso, professor? Ele vê a lista de parâmetros, isto é, a mensagem enviada! Se eu enviei um argumento, ele sabe que é o círculo; se eu enviei três argumentos, ele sabe que é o trapézio; se eu enviei dois argumentos, pode ser o retângulo ou o triângulo! E agora professor? Aí temos outro tipo de polimorfismo, que é tratado em tempo de execução. Em outras palavras, o polimorfismo permite que a mesma mensagem seja enviada a diferentes objetos e que cada objeto execute a operação que é mais apropriada a sua classe. Há uma relação estreita com o conceito de abstração, na medida em que um objeto pode enviar a mesma mensagem para objetos semelhantes, mas que implementam a sua interface de formas diferentes. O Polimorfismo pode ser Estático ou Dinâmico. O primeiro é também conhecido como polimorfismo por sobrecarga ou overloading, é representado com o nome do método igual e parâmetros diferentes. A decisão do método a ser chamado é tomada em tempo de compilação de acordo com os argumentos passados. Professor, o que você quer dizer com parâmetros diferentes? Pode ser uma diferença na quantidade, tipo ou ordem dos parâmetros. O segundo é também conhecido como

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

polimorfismo por sobrescrita, polimorfismo por inclusão, polimorfismo por herança, polimorfismo por subtipo, redefinição ou overriding. Ele está associado ao conceito de herança e é representado com o nome e parâmetros do método iguais. Nesse caso, a subclasse redefine o método da superclasse e a decisão do método a ser chamado é tomada em tempo de execução. Alguns alunos sempre me perguntam o que é a assinatura de um método! Vejamos: dois métodos possuem a mesma assinatura se, e somente se, tiverem o mesmo nome e os mesmos parâmetros (quantidade, tipo e ordem dos parâmetros). Algumas linguagens (Ex: Java) ignoram o tipo de retorno para verificar se métodos possuem a mesma assinatura; outras linguagens (Ex: C++) validam também o tipo de retorno para verificar se métodos possuem a mesma assinatura. Logo, a questão do tipo de retorno não é pacífica e dependerá da linguagem de programação utilizada. Bem... abaixo eu apresento os principais tipos de polimorfismo:

Comecemos pelo Polimorfimo Universal e Polimorfismo Ad-hoc! Grosso modo, o primeiro pode trabalhar com um número infinito de tipos; já o segundo pode trabalhar com um número finito de tipos. Dentro de cada uma dessas duas categorias, existem mais duas categorias: paramétrico e sobrescrita; sobrecarga e coerção. O polimorfismo paramétrico é também chamado por diversos autores de polimorfismo verdadeiro. O polimorfismo paramétrico é o tipo de polimorfismo que permite que se escreva um código genérico para servir os subtipos (que só serão descobertos em tempo de execução). Em outras palavras, um mesmo objeto pode ser utilizado como parâmetro em diferentes contextos sem necessidade de quaisquer alterações. Nesse caso, um elemento (Ex: função, classe, método, etc) pode ser escrito genericamente para que possa suportar valores idênticos sem depender do tipo.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Como assim, professor? Vamos imaginar que você tenha listas de diversos tipos: você tem uma lista de carros, uma lista de pessoas, uma lista de animais e uma lista de filmes. Ok! E você sabe que pode realizar várias operações nessas listas, tais como: acessar um elemento da lista, adicionar um elemento na lista, excluir um elemento da lista, atualizar um elemento da lista. Perceba que essas operações servem para qualquer lista, independentemente de seu tipo. Logo, por que criar métodos de acesso, adição, exclusão e atualização para todas as listas em vez de criar apenas um de cada? Veremos que não há necessidade disso! Uma única função é codificada e ela trabalhará uniformemente em um intervalo de tipos (funções paramétricas também são chamadas de funções genéricas). Bem, no Java, isso começou na versão 1.5 (com Generics). Lá, existe um tipo genérico chamado <List>. Toda vez que eu preciso instanciar uma lista, basta fazer:

List<TipoDaLista> NomeDaLista = new ArrayList<List>();

Dessa forma, caso eu queira instanciar uma lista de Strings, Integer ou um tipo criado por mim, basta fazer conforme o código a seguir:

List<String> listaDeString = new ArrayList<List>();

List<Integer> listaDeInteger = new ArrayList<List>();

List<TipoMeuQualquer> listaDeTipoMeuQualquer = new ArrayList<List>();

E olha o mais legal! Eu não preciso implementar todos os métodos de uma lista para cada tipo específico, basta fazer (por exemplo, para adição):

listaDeString.add(“Primeira String”);

listaDeInteger.add(4.000);

listaDeTipoMeuQualquer.add(TipoMeuQualquer);

Diga se isso não é genial e uma mão na roda! Pois é! Bem, o segundo tipo de polimorfismo universal, nós já vimos acima – a única novidade é que ele é chamado também de polimorfismo por inclusão, polimorfismo por herança ou polimorfismo por subtipo. Já o Polimorfismo ad-hoc se divide em sobrecarga e coerção – alguns autores mais rigorosos afirmam que polimorfismo ad-hoc não é polimorfismo. Por que? Porque não ocorrem em tempo de execução! Nós já vimos o primeiro tipo anteriormente, então não vamos repetir. Nosso interesse aqui é no polimorfismo de coerção. Ele é suportado através da sobrecarga de operadores, ou seja, ocorre quando se converte um elemento de um tipo no tipo apropriado para o método (é o famoso casting implícito). Ele permite que um argumento seja convertido para o tipo esperado por uma função, evitando assim um erro de tipo. Imaginem uma variável do tipo inteiro e uma variável do tipo real.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

É possível atribuir um valor inteiro a um tipo real (visto que ele é “maior”) de forma implícita. Nesse momento, ocorre uma coerção (também chamada conversão) de uma variável de um tipo em outro tipo. Agora vejam que bacana! Já recebi uma dúvida algumas vezes: Professor, um método pode sobrecarregar um método herdado? Em nossa página no Facebook, nós já discutimos sobre essa dúvida! Vejamos dois cenários... Primeiro, Classe Veículo possui um método dirigir(a) e uma Classe Carro (filha de Classe Veículo) possui um método dirigir(a), logo sobrescrevendo o método da classe-pai. Se eu inserir um método dirigir(a,b) na classe-filha, eu posso afirmar que esse método sobrecarrega o método dirigir(a) da classe-filha, mas não da classe-pai. E ele não sobrescreve o método da classe-pai, porque as assinaturas são diferentes. É impossível que um método realize sobrescrita e sobrecarga simultaneamente sobre um mesmo método. Segundo cenário: imaginem que eu não tenho uma sobrescrita de dirigir(a) na classe-filha. Eu tenho apenas dirigir(a) na classe-pai e dirigir(a,b) na classe-filha. Posso afirmar que esse método da classe-filha sobrecarrega dirigir(a)? Sim, porque dirigir(a) é herdado na classe-filha, logo – de certo modo – há uma sobrecarga do método implícito herdado da classe-pai. Na documentação do Java, há inclusive a seguinte referência:

In a subclass, you can overload the methods inherited from the superclass. Such overloaded methods neither hide nor override the superclass instance methods—they are new methods, unique to the subclasse.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Herança (Generalização/Especialização)

INCIDÊNCIA EM PROVA: Altíssima

A herança é outra forma de abstração utilizada na orientação a objetos que pode ser vista como um nível de abstração acima da encontrada entre classes e objetos. Na Herança, classes semelhantes são agrupadas em uma hierarquia. Cada nível dessa hierarquia pode ser visto como um nível de abstração. Trata-se de uma relação entre classes e, não, entre objetos. Antes de prosseguir, vamos falar um pouco sobre nomenclatura! A Classe que herda é chamada Subclasse, Classe-Filha, Classe Secundária ou Classe Derivada. A Classe que é herdada é chamada Superclasse, Classe-Pai/Mãe, Classe Primária ou Classe Base. A semântica do código da herança é variável de acordo com a linguagem de programação utilizada (Ex: em Java, utiliza-se a palavra-chave extends). Cada classe em um nível de hierarquia herda as características e o comportamento das classes às quais está associada nos níveis acima dela. Além disso, essa classe pode definir características e comportamento particulares. Dessa forma, uma classe pode ser criada a partir do reúso da definição de classes preexistentes. A herança facilita o compartilhamento de comportamento comum entre classes. Podemos dizer que se trata do mecanismo que permite que classes compartilhem atributos e métodos, com o intuito de reaproveitar o comportamento generalizado ou especializar operações e atributos.

HERANÇA SIMPLES HERANÇA MÚLTIPLA Quando uma subclasse herda diretamente de duas ou mais superclasses, trata-se de herança múltipla; já quando uma subclasse herda diretamente de apenas uma superclasse, trata-se de herança simples. Pegadinha clássica de concursos de tecnologia da informação: em orientação a objetos, é permitido herança múltipla? É claro que sim! O lance é que algumas linguagens de programação específicas não implementam herança múltipla (Ex: Java e C#). Já no contexto genérico de orientação a objetos, é permitida a herança múltipla! E por que algumas linguagens não a implementam? Porque ela pode causar alguns problemas de ambiguidade! Quando superclasses possuem membros homônimos e a subclasse não redefine esses membros,

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

no momento em que um objeto da subclasse tentar referenciar diretamente o membro homônimo das superclasses, o compilador não saberá a qual membro ele está se referindo. Um detalhe importante: uma subclasse sempre herdará métodos/atributos de suas superclasses – não importa se é herança simples ou herança múltipla. Você não pode dizer que você é um primata, mas não é um mamífero, porque todos os primatas são mamíferos. Vamos aproveitar para definir alguns conceitos importantes. Herdar é diferente de acessar! Se uma classe estende a outra, ela sempre herdará seus métodos/atributos. Não importa, por exemplo, se eles são privados – a subclasse sempre os herdará, mesmo que não os acesse! Como eu gosto de visualizar isso? Imaginem que um tio-avô distante deixe um cofre entupido de dinheiro para vocês. Por outro lado, esse cofre é completamente indestrutível e ele não deixou nenhuma senha. Nesse caso, vocês herdaram todo o dinheiro, mas não podem acessá-lo. Entendido? No mundo orientado a objetos acontece a mesma coisa: se uma subclasse é filha de uma superclasse, ela herdará absolutamente tudo, mesmo que ela não consiga acessar (que é o caso de membros privados). Já caiu em prova discursiva: qual a diferença entre Polimorfismo e Herança? Define-se herança como um mecanismo que permite ao programador basear uma nova classe na definição de uma classe previamente existente. Usando herança, sua nova classe herda todos os atributos e comportamentos presentes na classe previamente existente. Quando uma classe herda de outra, todos os métodos e atributos que surgem na interface da classe previamente existente aparecerão automaticamente na interface da nova classe. Já o polimorfismo permite que um único nome de método represente um código diferente, selecionado por algum mecanismo automático. Dessa forma, um nome pode assumir muitas formas e, como pode representar código diferente, o mesmo nome pode representar muitos comportamentos diferentes. Por fim, é importante falar do famoso Problema do Diamante. O que é isso, Diego? Trata-se de um problema específico que ocorre na herança múltipla, quando uma classe herda de duas classes que, por sua vez, herdam da mesma classe base.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Esse problema é assim chamado porque a estrutura de herança resultante se assemelha a um diamante, conforme imagem anterior. Note que a Classe A é a classe base; Classes B e C herdam da Classe A; e Classe D herda de ambas. O problema do diamante surge quando a classe D tenta acessar membros da classe A. Há ambiguidades sobre qual caminho seguir para acessar os membros da classe A: através da classe B ou da classe C. Essa ambiguidade pode causar problemas de consistência e complicações na manutenção do código. Cada linguagem de programação pode tentar resolver esse problema à sua maneira.

(CESPE / TCDF – 2023) O “problema do diamante”, que surge quando uma classe herda de duas classes que compartilham uma mesma classe pai, não resulta em conflitos de métodos ou ambiguidades na resolução de herança múltipla. _______________________

Comentários: o “problema do diamante” ocorre quando uma classe herda de duas classes que têm uma classe pai em comum, e isso pode resultar em ambiguidade de métodos e conflitos na resolução de herança múltipla (Errado).

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

ANÁLISE E PROJETO

Conceitos Básicos

INCIDÊNCIA EM PROVA: média

Bem, vamos começar a distinguir o que é Análise e o que é Projeto. Para tal, preciso que vocês memorizem, decorem, tatuem, componham uma música com a frase:

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

A Análise consiste em atividades necessárias para entender o domínio do problema, isto é, o que deve ser feito. É uma atividade de investigação, com foco no cliente. Já o Projeto consiste em atividades necessárias para entender o domínio da solução do problema, isto é, como deve ser feito. É uma atividade técnica, com foco no programador. Na Análise, a tecnologia de implementação e os requisitos não-funcionais não são modelados. Essa é uma tarefa do Projeto! Também não se pensa sobre soluções técnicas, pensa-se apenas em modelar funções, dados e relacionamentos do sistema. O modelo de análise deve ser aprovado pelo cliente – pode incluir até pequenas discussões sobre a solução, como sobre Interfaces Gráficas. O Modelo de Casos de Uso representa o aspecto funcional de um domínio de negócio e, de forma similar, o Modelo de Classes representa o aspecto estrutural de um domínio de negócio. Como é? Pessoal, um exemplo de Modelo de Classes é o Diagrama de Classes (da UML). Ele representa visualmente conceitos de um determinado domínio por meio de classes. É importante notar que o modelo de classes é utilizado durante a maior parte do desenvolvimento de um sistema orientado a objetos. Além disso, ele evolui durante as iterações do desenvolvimento do sistema. À medida que o sistema é desenvolvido, o Modelo de Classes é incrementado com novos detalhes. Existem três estágios sucessivos de abstração: análise, especificação e implementação.

Modelo de Classes de Análise

(ou Domínio)

Construído durante a atividade de análise, representa as classes de domínio do negócio. Não leva em consideração restrições inerentes à tecnologia a ser utilizada na solução de um problema.

Modelo de Classes de Especificação (ou Projeto)

Construído durante a atividade de projeto, estende o modelo de classes de análise e contém detalhes específicos inerentes à solução de software escolhida.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Modelo de Classes de

Implementação

Construído durante a atividade de implementação, estende o modelo de classes de projeto e contém detalhes específicos inerentes ao desenvolvimento das classes em alguma linguagem.

À medida que o sistema é desenvolvido, o modelo é incrementado com novos detalhes. O Modelo de Análise enfatiza o desenho lógico, a visão externa, conceitual, abstrata, caixa-preta, de alto nível de abstração. O Modelo de Projeto enfatiza o desenho físico, a visão interna, de implementação, concreta, caixa-branca, de baixo nível de abstração. Sabe-se que o Modelo de Análise é mais estável que o Modelo de Projeto. Sob a perspectiva organizacional, o primeiro sofre bem menos com mudanças tecnológicas, externas, regulatórias, etc. Além disso, é importante salientar que – na prática – muitas pessoas não fazem Análise e já partem para o Projeto. Inclusive, ela é uma disciplina opcional no RUP! Professor, eu posso não fazer? Pode, sim. Então para que ela existe? Imaginem se ocorre uma revolução tecnológica e todas as organizações comecem a implementar sistemas com um novo paradigma. Com um modelo de análise pronto, torna-se muito mais fácil adaptar o modelo de projeto. Caso contrário, tem-se que refazer o modelo de projeto do início. Em geral, as classes de análise evoluem para classes de projeto. A meta da Análise é identificar um esboço preliminar do comportamento do sistema. A meta do Projeto é transformar esse esboço preliminar em um conjunto implementável. O resultado é que há um refinamento detalhado e preciso quando alguém se move da Análise para o Design. Pessoal, a Análise apresenta quatro atividades principais:

1. Identificar Classes

2. Identificar Responsabilidades

3. Identificar Atributos

4. Identificar Relacionamentos

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Em 1992, Ivar Jacobson (aquele da UML) propôs uma técnica chamada Análise de Robustez, que propunha a categorização das classes de acordo com sua responsabilidade: Classe de Fronteira; Classe de Controle; e Classe de Entidade.

CLASSE DE FRONTEIRA

Classe utilizada para modelar a interação entre um ator e o sistema. Para cada ator, é identificada pelo menos uma classe de fronteira para permitir sua interação com o sistema. Então, uma classe de fronteira existe para que o sistema se comunique com o mundo exterior, logo elas são altamente dependentes do ambiente.

A Interação entre sistema e atores envolve transformar e converter eventos, bem como observar mudanças na apresentação do sistema (como a interface). As classes de fronteira modelam as partes do sistema que dependem do ambiente. As classes de entidade e de controle modelam as partes que são independentes de fatores externos ao sistema. Logo, alterar a GUI ou o protocolo de comunicação significa alterar só classes de fronteira e, não, classes de entidade e de controle. As classes de fronteira também facilitam a compreensão do sistema, pois definem suas fronteiras. Elas ajudam no design, fornecendo um bom ponto de partida para identificar serviços relacionados. Algumas classes de fronteira comuns são janelas, protocolos de comunicação, interfaces de impressora, sensores e terminais. Se você estiver usando um construtor GUI, não será necessário modelar partes da interface de rotinas (botões, por exemplo) como classes de fronteira separadas. Em geral, a janela inteira é o objeto de fronteira mais refinado. As classes de fronteira também são úteis para capturar interfaces para APIs possivelmente não orientadas a objetos (como código mais antigo, por exemplo). Você deve modelar as classes de fronteira de acordo com o tipo de fronteira que elas representam. A comunicação com outro sistema e a comunicação com um ator humano (através de uma interface do usuário) têm objetivos diferentes. Durante a modelagem da interface do usuário, a principal preocupação deve ser a forma como a interface será apresentada ao usuário. Durante a modelagem da comunicação do sistema, a principal preocupação deve ser o protocolo de comunicação. Um objeto de fronteira poderá durar mais que uma instância de caso de uso, porém costumam ter a mesma duração da instância de caso de uso.

CLASSE DE controle

Classe utilizada para controlar a lógica de execução ou negócio correspondente a cada caso de uso. Servem como uma ponte de comunicação entre objetos de fronteira e objetos de entidade. Decidem o que o sistema deve fazer quando um evento externo relevante ocorre, agindo como coordenador para a realização de casos de uso.

Como objetos de controle (instâncias de classes de controle) geralmente controlam outros objetos, o comportamento de objetos de controle é do tipo coordenador. As classes de controle encapsulam um comportamento específico de caso de uso. O comportamento de um objeto de controle está estreitamente relacionado à realização de um caso de uso específico. Em muitos cenários, é possível até dizer que os objetos de controle "executam" as realizações de casos de uso.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

No entanto, se as tarefas de caso de uso estiverem intrinsecamente relacionadas, alguns objetos de controle poderão participar de mais de uma realização de casos de uso. Além disso, vários objetos de controle de diferentes classes de controle podem participar de um único caso de uso. Nem todos os casos de uso exigem um objeto de controle. Se o fluxo de eventos em um caso de uso estiver relacionado a um objeto de entidade, um objeto de fronteira poderá realizar o caso de uso em cooperação com o objeto de entidade. As classes de controle podem ajudar a entender o sistema, pois representam a dinâmica do sistema, controlando as principais tarefas e os fluxos de controle. Quando o sistema executar o caso de uso, um objeto de controle normalmente será criado. Os objetos de controle geralmente desaparecem após a execução do correspondente caso de uso. Observe que uma classe de controle não controla tudo o que é necessário em um caso de uso. Em vez disso, ela coordena as atividades de outros objetos que implementam a funcionalidade.

Classe de entidade

Classe utilizada para armazenar a informação que é manipulada ou processada pelo caso de uso, partindo do domínio do negócio. Geralmente, essas classes armazenam informações persistentes. Há várias instâncias ou objetos de uma mesma classe de entidade coexistindo dentro do sistema.

Os objetos de entidade (instâncias de classes de entidade) são usados para manter e atualizar informações sobre alguns fenômenos, como um evento, uma pessoa ou algum objeto real. Esses objetos geralmente são persistentes, precisando de atributos e relacionamentos durante muito tempo, algumas vezes durante todo o ciclo de vida do sistema. Um objeto de entidade geralmente não é específico para uma realização de casos de uso. Às vezes, um objeto de entidade não é nem mesmo específico para o próprio sistema. Os valores de seus atributos e relacionamentos costumam ser fornecidos por um ator. Um objeto de entidade também pode ajudar a executar tarefas internas do sistema. Seu comportamento pode ser tão complicado quanto o de outros estereótipos de objeto. No entanto, ao contrário de outros objetos, esse comportamento está relacionado ao fenômeno que o objeto de entidade representa. Os objetos de entidade independem do ambiente (os atores). Os objetos de entidade representam os conceitos-chave do sistema que está sendo desenvolvido. Exemplos típicos de classes de entidade em um sistema bancário são Conta e Cliente. Em um sistema de gerenciamento de redes, os exemplos são Nó e Link. Se o fenômeno que você deseja modelar não for usado por outras classes, será possível modelá-lo como um atributo de uma classe de entidade ou mesmo como um relacionamento entre classes de entidade. Por outro lado, se o fenômeno for usado por qualquer outra classe do modelo de design, será preciso modelá-lo como uma classe. As classes de entidade fornecem um outro ponto de vista do sistema, pois mostram a estrutura lógica dos dados, que pode ajudá-lo a compreender o que o sistema deve oferecer aos usuários. A segunda atividade se refere à identificação de responsabilidades.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Essa identificação e categorização implica que cada classe seja especialista em realizar uma tarefa específica que comporá o modelo de análise: comunicar-se com atores (Fronteira); manter as informações do sistema (Entidade); e coordenar a realização de um caso de uso (Controle). As atividades seguintes são bastante intuitivas e fáceis de entender. A terceira atividade se refere à identificação de atributos, em que se busca apenas descobrir quais são os atributos, sem nenhuma preocupação sobre qual seu tipo (String, Date, Time, Integer, etc). Um bom conhecimento do domínio do problema é extremamente útil nesta fase. Por fim, identificam-se os relacionamentos como associações, agregações, composições, dependências, generalizações, especializações, entre outros. Fim da Análise, agora nós sabemos o que fazer, chegou a hora de saber como fazer. Partamos, então, para o Projeto! Vamos falar bastante sobre arquitetura de software, estrutura e comportamento de classes. A Arquitetura de Software é a organização/estrutura dos componentes significativos do sistema que interagem por meio de interfaces. Uma arquitetura bem projetada e solidamente desenhada deve ser capaz de atender aos requisitos funcionais e não-funcionais e ser suficientemente flexível para suportar requisitos voláteis. A arquitetura é importante, pois permite uma comunicação efetiva entre as partes interessadas, abrangendo a compreensão, negociação e consenso. Ademais, permite decisões tempestivas, isto é, possibilita correção e validação do sistema antes da implementação. Por fim, permite uma reutilizável em sistemas com características similares. Uma boa arquitetura deve ter componentes projetados com baixo acoplamento e alta coesão. Como é isso, professor? Pessoal, esse é outro mantra que eu preciso que vocês memorizem! Acoplamento trata do nível de dependência entre módulos de um software. Já a Coesão trata do nível de responsabilidade de um módulo em relação a outros. Professor, por que é bom ter baixo acoplamento? Porque se os módulos pouco dependem um do outro, modificações de um não afetam os outros, além de prejudicar o reúso. Professor, por que é bom ter alta coesão? Porque se os módulos têm responsabilidades claramente definidas, eles serão altamente reusáveis independentes e simples de entender. Uma forma de organizar a arquitetura de um sistema complexo em partes menores é por meio de camadas, em que cada uma corresponderá a um conjunto de funcionalidades de um sistema– sendo que as funcionalidades de alto nível dependerão das funcionalidades e baixo nível. A separação em camadas fornece um nível de abstração através do agrupamento lógico de subsistemas relacionados. Parte-se do princípio de que camadas de abstração mais altas devem depender das camadas de abstração mais baixas. Isso permite que o sistema de software seja mais portável e modificável. Mudanças em uma camada mais baixa, que não afetem a sua interface, não implicarão mudanças nas camadas superiores; e mudanças em uma camada mais alta, que não impliquem a criação de um novo serviço em uma camada mais baixa, não afetarão camadas inferiores.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

==76484==

A arquitetura em camadas permite melhor separação de responsabilidades; decomposição de complexidade; encapsulamento de implementação; maior reúso e extensibilidade. No entanto, podem penalizar o desempenho do sistema e aumentar o esforço/complexidade de desenvolvimento do software. Arquiteturas em duas camadas já foram dominantes, mas – para minimizar o impacto de mudanças – decidiu-se separar a camada de negócio da camada de interface gráfica, gerando três camadas:

Camada de apresentação

Possui classes que contêm funcionalidades para visualização dos dados pelos usuários (Por exemplo: classes de fronteiras para atores humanos). E qual a real importância dela? Ela tem o objetivo de exibir informações ao usuário e traduzir ações do usuário em requisições às demais partes dos sistemas.

Camada lógica de

negócio

Possui classes que implementam as regras de negócio no qual o sistema será implantado. Ela realiza computações com base nos dados armazenados ou nos dados de entrada, decidindo que parte da camada de acesso deve ser ativada com base em requisições provenientes da camada de apresentação.

Camada de acesso

Possui classes que se comunicam com outros sistemas para realizar tarefas ou adquirir informações para o sistema. Tipicamente, essa camada é implementada utilizando algum mecanismo de armazenamento persistente. Pode haver uma subcamada dentro desta camada chamada Camada de Persistência.

O padrão de arquitetura em três camadas mais utilizado no mercado é designado Model-View- Controler (MVC):

Modelo

Responsável por modelar os dados da aplicação e regras de negócio. Tem o foco em armazenamento, manipulação e geração de dados. Objetos do Modelo são geralmente reusáveis, distribuídos, persistentes e portáveis.

Visão

Responsável pela apresentação dos dados aos usuários. Ele recebe entradas de dados e apresenta resultados. Essa camada não persiste nenhum dado no sistema e também não busca dados, apenas os renderiza em tela.

controle

Responsável por definir o comportamento da aplicação. Processa e responde a eventos, geralmente ações do usuário, e pode invocar alterações no modelo. Realiza, também, a validação de dados do usuário.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

RESUMO

VANTAGENS DO PARADIGMA ORIENTADO A OBJETOS

TIPO DE ATRIBUTO DESCRIÇÃO

ATRIBUTO DE CLASSE

ATRIBUTO DE INSTÂNCIA

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

TIPO DE método DESCRIÇÃO

Método DE CLASSE

Método DE INSTÂNCIA

TIPO DE ligação DESCRIÇÃO

Early binding ^{Também conhecida como Ligação Estática, ocorre quando o método a ser}

invocado é definido em tempo de compilação.

Late binding ^{Também conhecida como Ligação Dinâmica, ocorre quando o método a ser}

invocado é definido em tempo de execução.

mensagem

Trata-se de requisições enviadas de um objeto para outro com o intuito de receber algo em retorno por meio da execução de uma operação. Uma mensagem é composta por: objeto, a quem a mensagem é endereçada; nome do método ou serviço que se deseja executar; e parâmetros necessários ao método (se existirem).

Abstração

Trata-se da habilidade de concentrar nos aspectos essenciais de um contexto qualquer, ignorando características menos importantes ou acidentais. Em modelagem orientada a objetos, uma classe é uma abstração de entidades existentes no domínio do sistema de software.

interface

Trata-se de um contrato sem implementação entre dois ou mais objetos. É utilizada para reduzir o acoplamento, facilitando o reuso de classes. Elas não possuem atributos, apenas assinaturas dos métodos – sendo que todos os métodos são, por padrão, abstract e public.

características Interfaces Classe abstrata

Herança Múltipla ^Suporta

Herança Múltipla. Pode implementar diversas interfaces.

Não suporta Herança Múltipla. Não pode estender várias classes abstratas.

Implementação ^{Não pode conter qualquer método concreto,}

apenas abstratos.

Pode conter métodos concretos ou abstratos.

Constantes ^{Suporta somente constantes estáticas.}

Suporta constantes estáticas e de instância.

Encapsulamento ^{Métodos e membros devem sempre ser}

públicos por padrão.

Métodos e membros podem ter qualquer visibilidade.

Membros de Dados ^{Não contém atributos, apenas assinatura de}

métodos.

Pode conter atributos.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Construtores ^{Não contém construtores.}

Contém construtores.

Velocidade ^{Em geral, são mais lentas que classes}

abstratas.

Em geral, são mais rápidas que interfaces.

encapsulamento

Trata-se de uma forma de restringir o acesso ao comportamento interno de um objeto de modo a evitar que eles sofram acessos indevidos. A ideia é tornar o software mais flexível, fácil de modificar e de criar novas implementações.

MODIFICADOR/ESPECIFICADOR CLASSE PACOTE SUBCLASSE TODOS

uml

PÚBLICO + x x x x PROTEGIDO # x x PACOTE ~ x x PRIVADO – x

MODIFICADOR/ESPECIFICADOR CLASSE PACOTE SUBCLASSE TODOS

JAVA

PÚBLICO + x x x x PROTEGIDO # x x x DEFAULT ~ x x PRIVADO - x

Polimorfismo

Trata-se capacidade de abstrair várias implementações diferentes em uma única interface. Em outras palavras, é o princípio pelo qual duas ou mais classes derivadas da mesma superclasse podem invocar métodos que têm a mesma assinatura, mas comportamentos distintos.

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

HERANÇA

Trata-se do princípio que permite que classes compartilhem atributos e métodos. É utilizada com a intenção de reaproveitar código ou comportamento generalizado ou especializar operações ou atributos.

HERANÇA SIMPLES HERANÇA MÚLTIPLA

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

==76484==

Modelo de Classes de Análise

(ou Domínio)

Modelo de Classes de Especificação (ou Projeto)

Construído durante a atividade de projeto, estende o modelo de classes de análise e contém detalhes específicos inerentes à solução de software escolhida.

Modelo de Classes de

Implementação

Construído durante a atividade de implementação, estende o modelo de classes de projeto e contém detalhes específicos inerentes ao desenvolvimento das classes em alguma linguagem.

CLASSE DE FRONTEIRA

CLASSE DE controle

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

Classe de entidade

Camada de apresentação

Camada lógica de

negócio

Camada de acesso

Modelo

Visão

controle

PARA MAIS DICAS: www.instagram.com/professordiegocarvalho

Equipe Informática 2 (Diego Carvalho), Diego Carvalho

Aula 06 - Prof. Diego Carvalho e Fernando Pedrosa

ALE-GO (Desenvolvimento de Sistemas) Engenharia de Software

www.estrategiaconcursos.com.br

03147577244 - Wislan Pablo Santos

206

PARADIGMA ORIENTADO A OBJETOS

Conceitos Básicos

VANTAGENS DO PARADIGMA ORIENTADO A OBJETOS

Classes e Objetos

São componentes de um objeto: identidade, estado (propriedades) e comportamento (operações). A identidade é responsável por distinguir um objeto dos outros, isto é, eles são únicos, mesmo que sejam instâncias de uma mesma classe e que tenham os mesmos valores de variáveis.

Atributos

TIPO DE ATRIBUTO DESCRIÇÃO

ATRIBUTO DE CLASSE

ATRIBUTO DE INSTÂNCIA

Métodos

TIPO DE método DESCRIÇÃO

Método DE CLASSE

Método DE INSTÂNCIA

TIPO DE ligação DESCRIÇÃO

Aqueles que já conhecem um pouco sobre orientação a objetos, respondam-me: Qual desses tipos de ligação é o mais comum quando utilizamos polimorfismo? Late Binding!

Mensagens

Abstração

Interface

características Interfaces Classe abstrata

Herança Múltipla Suporta

Encapsulamento

MODIFICADOR/ESPECIFICADOR CLASSE PACOTE SUBCLASSE TODOS

uml PÚBLICO + x x x x

PROTEGIDO # x x

PACOTE ~ x x PRIVADO – x

MODIFICADOR/ESPECIFICADOR CLASSE PACOTE SUBCLASSE TODOS

JAVA

PÚBLICO + x x x x PROTEGIDO # x x x DEFAULT ~ x x PRIVADO - x

Polimorfismo

Dessa forma, caso eu queira instanciar uma lista de Strings, Integer ou um tipo criado por mim, basta fazer conforme o código a seguir:

E olha o mais legal! Eu não preciso implementar todos os métodos de uma lista para cada tipo específico, basta fazer (por exemplo, para adição):

In a subclass, you can overload the methods inherited from the superclass. Such overloaded methods neither hide nor override the superclass instance methods—they are new methods, unique to the subclasse.

Herança (Generalização/Especialização)

(CESPE / TCDF – 2023) O “problema do diamante”, que surge quando uma classe herda de duas classes que compartilham uma mesma classe pai, não resulta em conflitos de métodos ou ambiguidades na resolução de herança múltipla. _______________________

ANÁLISE E PROJETO

Conceitos Básicos

Bem, vamos começar a distinguir o que é Análise e o que é Projeto. Para tal, preciso que vocês memorizem, decorem, tatuem, componham uma música com a frase:

Modelo de Classes de Análise

(ou Domínio)

Modelo de Classes de Especificação (ou Projeto)

Modelo de Classes de

Implementação

Em 1992, Ivar Jacobson (aquele da UML) propôs uma técnica chamada Análise de Robustez, que propunha a categorização das classes de acordo com sua responsabilidade: Classe de Fronteira; Classe de Controle; e Classe de Entidade.

CLASSE DE FRONTEIRA

CLASSE DE controle

Classe de entidade

Camada de apresentação

Camada lógica de

negócio

Camada de acesso

O padrão de arquitetura em três camadas mais utilizado no mercado é designado Model-View- Controler (MVC):

Modelo

Visão

controle

RESUMO

VANTAGENS DO PARADIGMA ORIENTADO A OBJETOS

TIPO DE ATRIBUTO DESCRIÇÃO

ATRIBUTO DE CLASSE

ATRIBUTO DE INSTÂNCIA

TIPO DE método DESCRIÇÃO

Método DE CLASSE

Método DE INSTÂNCIA

TIPO DE ligação DESCRIÇÃO

mensagem

Abstração

interface

características Interfaces Classe abstrata

Herança Múltipla Suporta

encapsulamento

MODIFICADOR/ESPECIFICADOR CLASSE PACOTE SUBCLASSE TODOS

uml

MODIFICADOR/ESPECIFICADOR CLASSE PACOTE SUBCLASSE TODOS

JAVA

Polimorfismo

HERANÇA

HERANÇA SIMPLES HERANÇA MÚLTIPLA

Modelo de Classes de Análise

(ou Domínio)

Herança Múltipla ^Suporta

Herança Múltipla ^Suporta